Players had no way to leave their name on a run, and the results web app
needs a stable per-run id to look a run up later.

A third button, RECORD, sits between CONTINUE and QUIT. Choosing it opens
an arcade name entry, saves the run to score_records.json, then shows the
id the run was filed under so the player can photograph it.

New session files:

Campus.cs and CampusBuildConfig.cs hold the cabinet's campus identity.
The config loads from Resources and falls back to a runtime instance with
a valid campus string, so a missing asset cannot write an empty campus
field. A cabinet switches campus by editing one asset.

ScoreRecord.cs is the JSON contract the web app reads: id, name, score,
date, campus, lastPlaced. ScoreRecordFile exists only because
JsonUtility cannot deserialize a top-level array; the file on disk is
still a raw array.

ScoreRecordStore.cs loads, appends, and saves. Ids come from the highest
existing suffix rather than the record count, so deleting or
hand-editing a row cannot hand out an id already printed on someone's
phone. Dates and ids format with invariant culture. A missing, empty, or
corrupt file reads as zero records, because a bad save must never block
a player from leaving the results screen.

New UI files:

RecordNameEntryController.cs walks the glyph grid with Left and Right
only, since the cabinet menu map has no up or down. Confirm inserts,
DONE or the physical Enter key saves, and Back deletes then cancels once
the name is empty. RecordConfirmController.cs shows the saved id and
takes a final Continue or Quit. RecordFlowLayoutBuilder.cs builds both
overlays from Style1 tokens, per results panel, so each half of a split
screen owns its own overlays and its own input provider.

Results screen changes:

ResultScreenLayoutBuilder adds the RECORD button to the row.
ResultScreenController replaces the two-way Continue/Quit flag with a
three-way selection that skips Record when it is hidden, and re-spans
the button row for two or three buttons.

Record is gated on allowNavigation rather than a list of game modes, so
it covers 1P, Player 1 in VS Bot, both players in human 2P, and battle
mode, while the bot's spectator panel keeps the original two buttons.

Record opens an overlay instead of leaving the scene, so it is never
reported to TwoPlayerGameCoordinator as a Continue. After a save, the
results buttons are re-armed before the confirm is reported, because the
other player may have chosen the opposite option and the coordinator
will ask for another confirm.

Co-authored-by: Cursor <cursoragent@cursor.com>